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ABSTRACT 


This paper describes XSQuirrel, a new XML query language 
that transforms a document into a sub-document, i.e. a tree 
where the root-to-leaf paths are a subset of the root-to-leaf 
paths from the original document. 

We show that this type of queries is extremely useful for 
various applications (e.g. web services) and that the cur- 
rently existing query languages are poorly equipped to ex- 
press, reason and evaluate such queries. In particular, we 
emphasize the need to be able to compose such queries. We 
present the XSQuirrel language with its syntax, semantics 
and two language specific operators, union and composition. 

For the evaluation of the language, we leverage well es- 
tablished query technologies by translating XSQuirrel ex- 
pressions into XPath programs, XQuery queries or XSLT 
stylesheets. 

We provide some experimental results that compare our 
various evaluation strategies. We also show the runtime ben- 
efits of query composition over sequential evaluation. 


Categories and Subject Descriptors 
H.2.3 [Database Management]: Query Languages 


General Terms 


Algorithms, Performance, Languages 


Keywords 
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1. INTRODUCTION 


Let there be no misunderstanding. In this paper, we will 
try to sell you yet another query language for XML. Our lan- 
guage has a catchy name, but more importantly we think it 
solves a real problem, in the current web services architec- 
ture, that is not properly addressed by the existing query 
languages for XML. 

XML is about trees, and people are rather familiar with 
tree structures: genealogical trees, tree hierarchy in file sys- 
tems or bookmarks, etc. Yet, the current query infrastruc- 
ture for XML does not support a simple operation that con- 
sists of taking a document and return a sub-document. As 
we will show, this is a quite natural operation, that happens 
to be very useful in a lot of application domains. 
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But let’s start by defining what we mean by sub-document. 
The notion of a sub-document is a totally natural concept 
when you think about it. This is nothing more than the 
counterpart of the result of a select-project (SP) in the rela- 
tional model. 

The relational model deals with tables. SP operations 
remove rows and columns to produce sub-tables. XML deals 
with documents and we want to remove sub-trees to produce 
sub-documents. 

Note that sub-documents are not properly captured by 
existing query languages. XPath consumes a document to 
produce a node-set. XQuery creates new node ids. We will 
elaborate more in the next section. 


1.1 The notion of sub-document 


An XML document is a tree defined by D = (N, V, A, <a) 
where: (i) N is the set of nodes in the document with no 
a designated node which is the document’s root; (ii) V C 
N x N is the parent/child relationship between nodes; (iii) A 
is a function that associates each node with a label; and (iv) 
<q is an ordering relation on the nodes of the document. 

A sub-document D' = (N',V',X’, <4) of an XML docu- 
ment D = (N,V, A, <a) is defined as follows: (i) D and D’ 
have the same root; (ii) N’ C N; (iii) V’ C V; (iv) AY = A 
and (v) <q=<a. 

Another way to look at it is to consider a document as 
the set of root-to-leaf paths. In the example of Fig. 1, the 
set is: 

{/A/B/C,/A/B/D/DD, /A/B/D/EE, /A/B/F/FF , 
/A/B/F/GG,/A/B/H,/A/B/D/DD, /A/B/D/EE, /A/B/D/II}. 

A sub-document corresponds exactly to a subset. For our 
example, the subset is: 
{/A/B/D/DD , /A/B/D/EE, /A/B/H, /A/B/D/DD, 

/4/B/D/EE, /A/B/D/IT}. 

Yet another way is to say that a sub-document is the 
original document where some sub-trees (down to the leaves) 
have been removed. 


1.2 The use for sub-documents 


There are many uses for sub-documents. Sub-documents 
can be used to define XML views. Sub-documents corre- 
spond to join-free queries. This is natural for data integra- 
tion. For instance, one can define views over XML sources, 
each view being a sub-document of the actual source. These 
views can then be joined to produce another document. Sub- 
documents can also be used to define access control over 
XML data. A sub-document corresponds to the data that 
can be seen. 

Sub-documents are also very useful for data merging and 


synchronization because the structure of the original docu- 
ment is preserved. Algorithms like the deep union [8] require 
such information. 

Finally, we think that sub-documents can also be used 
for distributed query processing of XML data. First, they 
permit to ship around only the relevant parts of the docu- 
ment. Given the verbosity of XML, this can be a huge save 
in bandwidth-conscious environments. Second, they permit 
to ship enough structure (path to the root) to conduct semi- 
join [19] like algorithms over XML. 


1.3 One very concrete application: 
user profile management in GuP***" 


We now describe how the notion of sub-document natu- 
rally came into play for the privacy conscious management 
of user profile information. 

In today’s networks, user profile information (e.g. address 
book, presence, location, calendar, etc.) is scattered all over. 
Various initiatives [1, 14] are standardizing XML-based so- 
lutions to offer a web service single point of access for this 
information. 

The GUPS" project [22, 2, 13, 21] at Bell Labs goes in 
the same direction, with a dual emphasis on integration and 
access control. In this context, we are looking to: (1) inte- 
grate, into a common schema and on a per user basis, XML 
data coming from various sources; (2) permit users to define 
access control rules over the integrated data; and (3) let ap- 
plications query the data while enforcing user privacy. This 
yields the need for the following concepts: 

e a query, defining what portion of the user profile is 
requested. 

e a mapping rule, defining where a portion of the user 
profile is stored (mapping to a data source). 

e an access control rule, defining under what condi- 
tion a portion of the user profile can be accessed (map- 
ping to boolean function). 

Quite naturally, a portion of the user profile corresponds 
to a sub-document of the user profile. One question we have 
to answer is how we can express sub-documents. 

Moreover, for efficiency, we want to avoid to retrieve data 
that is not needed in the final answer either because it is not 
part of the query or because it not visible due to access con- 
trol rules. Therefore, we envision the processing of an incom- 
ing query Q as follows. Given a user profile D, a set of map- 
pings {M;}, a set of access control rules {AC'R;}, we want to 
compute D’ = f({Mi}, {ACR;}, Q, D). Or maybe even bet- 


ter, we would like to compute D’ = g({M;}, {ACR;}, Q, )(D). 


This way, instead of having to send the query and apply the 
access control on the result that is sent back, we send to each 
source a query compatible with the access control. This is 
much more efficient. 


The rest of the paper is organized as follows. In Section 2, 
we explain why currently available query languages are not 
appropriate for this new kind of queries. We then present 
the language itself, with its syntax, semantics and opera- 
tors (union and composition). In Section 5, we describe 
various strategies to evaluate XSQuirrel queries over XML 
documents by translating expressions into other query lan- 
guages: XPath, XQuery and XSLT. We then present some 
experimental results that (1) compare the various evaluation 
strategies and (2) show the benefit of composition operator, 
for queries and data over some XMark [23] dataset. Some 
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Figure 1: Original document D and sub-document D’ 
defined by qı(D) (grey marking). 


related work is discussed in Section 6, before we offer our 
conclusions and some future work. 


2. A NEW LANGUAGE, REALLY? 


In this section we argue that we need a new language 
because the existing ones do not address the issue of sub- 
document queries properly. We explain the shortcomings of 
XPath, XQuery and XSLT and list some requirements for 
the design of our new language. 


2.1 Why not XPath? 


The XPath 1.0 [10] has been designed mostly as a navi- 
gation language that returns a subset of the nodes of a doc- 
ument. For instance, XSLT uses XPath heavily to match 
patterns that need transformation. 

When applied on a document, XPath returns a nodeset 
and not a sub-document. From the nodes, it is always pos- 
sible to reconstruct the document (using the context to find 
the ancestors of the current node up to the root), but this 
is not the default behavior and the application using XPath 
needs to perform this reconstruction. Moreover, when the 
context is lost (e.g. data shipped from a remote site), this 
information is lost. 

The main problem with XPath is that the input and the 
output of the query are not the same domain and therefore 
queries cannot be composed. 


2.2 Why not XSLT? 


Even though XSLT has the notion of document built-in 
in its semantics with templates being applied to the current 
document, it is a language hard to reason about because of 
its rule-based nature. 

Moreover, the output of an XSLT transformation is not 
necessarily a document. 


2.3. Why not XQuery? 


XQuery [9] is the general purpose query language for XML. 
The problem with XQuery is three-fold. 

First, in our setting, this is like a hammer to kill a fly, 
since sub-document queries are restricted in nature (remem- 
ber the analogy with select-project in the relational algebra). 
Moreover, XQuery does not know about the sub-document 
semantics. 

Second, XQuery processes a document by first decon- 
structing it into FLWR bindings and then reconstructing it. 
Not only does this imply a lot of syntax, it also requires the 
creation of new node ids. When the sub-document consists 
of only a few nodes removed from the original document, 
this is a lot of overhead. 


Third, XQuery is so rich and powerful that it is very hard 
to reason about. XQuery is by nature composable. For 
two queries Qı and Q2 over document D, you can always 
represent the composed query as let $x:=Qi(D) return 
Qe ($x). But it might be hard to optimize such an expres- 
sion. 


2.4 A new language 


Based on the previous considerations, we decided to go 
for a new domain specific language that would fit our needs 
and fulfill the following requirements: 
built-in sub-document semantics 
composability of queries 
expressive enough to be useful 
simple enough to be reasoned about and optimized 
concise syntax 
friendly with other XML languages (e.g. reuse of syn- 
tax, translation to other languages for evaluation) 


3. THE XSQuirrel LANGUAGE 


In this section we present the XSQuirrel language. It is 
based on XPath 1.0 and therefore XSQuirrel is rather a fam- 
ily of languages, depending on which fragment of XPath 1.0 
we decide to use. 

All these languages — of course — share the same semantics 
but the details of some of the algorithms may be different, 
depending on the expressive power of the fragment we use. 
For a detailed study of these issues and a more theoretical 
presentation of XSQuirrel, we refer the reader to [5]. 

In the rest of the section, we will consider a very limited 
fragment of XPath‘. This is the one we are using in the 
context of GUPStS" and it has shown so far to be expres- 
sive enough for our application domain of privacy conscious 
integration of XML data. 


3.1 Syntax 


XSQuirrel expressions are built from a finite set of labels 
(e.g., tags, names) © of an XML schema S. The fragment of 
the language that we consider in this paper is syntactically 
defined as follows: 


p e | l | p/p | p/(p U p) | pla] 


where e€, l denote the empty path (”.” in XPath) and a 
name in X respectively; U stands for union; ”/” stands for 
XPath concatenation but here is also used as the XPath 
child axis. q in plq] is called a qualifier and is defined by: 
q:=p|label =v | not(q). 

From XPath 1.0, we have kept the child and attribute axis 
and a restricted form of value-based predicates. 
EXAMPLE We give below some examples of XSQuirrel 


expressions. 
qa: /A/B/(DUH) 
q2: /A/B[H]/(D/DD UF) 
q3: /A/(B[C]U B[H]/(D/II U F/FF)) 
qı: /A/B[D/EE]/(D/DDU HUF) 


Query qi for instance returns D and H nodes, that are 
children of B nodes, themselves children of A nodes. Along 
with these nodes, their descendants, and ancestors up to 
the root node of the document on which qi is evaluated are 
returned. 


1The reason why we emphasize this point is that some of the 
results and conclusions we present here might be different for 
larger fragments of the language that are still under study. 
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3.2 Semantics 


Intuitively, the result of the evaluation of an XSQuir- 
rel expression q on a document D is document q(D) (sub- 
document of D) obtained as follows: 
1. evaluate q using the usual XPath 
2. for each node n obtained from the previous step, get 
its descendant nodes, and its ancestor nodes up to the 
root of D 

3. finally, g(D) is constructed by removing all nodes of 
D that are not in the set of nodes from the previous 
step (note that the resulting document q(D) is a sub- 
document of D). 


EXAMPLE Consider the XML document D illustrated 
in Fig. 1 (ignore the grey marking for now) and query qi 
given in Example 3.1. The result of evaluating qi over D 
is sub-document qi(D) where the nodes have been marked 
in grey. More specifically, this document is defined by the 
D and H nodes returned when evaluating qı as an XPath 
expression on D, their descendants and ancestors up to the 
root node of D. 

More formally: the result of evaluating an XSQuirrel 
expression q against a document D(N,V,A,<a) is a sub- 
document D'(N', V’, A’, <q) of D such that: (i) N’ is defined 
as: 


N=[D]o U rll LU alld 


ne[[D]]q ne[[D]]q 


where n|[D]]» denotes the set of nodes returned by evalu- 
ating XPath expression p on the node n of document D (n 
is omitted when it is the root), |}. and ff“ are the XPath 
descendant and ancestor axis respectively. and (ii) V’ = 
{(m1,n2) E V |m, n2 E N’}. 


3.3 Language operators 


At the level of the language we define two language (i.e. 
syntactic) operators — union (U) and composition (0) — such 
that: YD, (Qı U Q2)(D) = Qı(D) U Q2(D) and YD, (Qı © 
Q2)(D) = Qı (Q2(D)). Here the union of two sub-documents 
corresponds to the union of their nodes. 

For lack of space, we only provide the intuition for the 
algorithms of union and composition. We refer the reader 
to [5] for a more formal presentation. 


3.3.1 Union 


This operator is pretty straightforward. For both XSQuir- 
rel expressions, we can naturally derive two sets of XPath 
expressions by distributing over U. We can then take the 
union (as sets) of the two, recombine them as an XSQuirrel 
expression and normalize them. 

We provide an example below. The evaluation of the 
queries over a document is presented in Fig. 2. 


q2: /A/B[H]/(D/DD U F) 
q3: /A/(B[C] U B[H]/(D/II U F/FF)) 


q2 Uzq q3: /A/(BIC] U B[H]/(D/(DD U II) U F)) 


3.3.2 Composition 


This operator is more complicated because it is not sym- 
metric. We distinguish between the inner (Q;) and the outer 
expression (Qo). 

The core of the composition algorithm must ensure two 
things. First, that the final expression is as selective as 
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Figure 2: Union: q2(D) (left), q3(D) (middle) and (q2 Uzq q3)(D) (right). 


the more selective of the two: /A/B composed with /A/B/C 
is /A/B/C. Second, that the predicates from the outer ex- 
pression correspond to paths that are defined in the inner 
expression. This makes perfect sense when you think of the 
inner query as the one defining an access control view for 
instance. 


EXAMPLE Here is an example. 


Qo /A/(B[C] U B[H]/(D/IT U F/FF)) 
Qi /A/B|D/EE]/(D/DD U HUF) 
Qo oQi 


We see that node B[C] of Qo does not appear in the com- 
posed query (the path /A/B/C for node B[C] is not satis- 
fied by the inner query). Node B[H][D/EE] is created from 
nodes B[H] and B[D/EE] of the outer and inner queries, re- 
spectively. Node D (and its children) disappears from the 
resulting query since the outer query (Qo) requests II nodes 
but the inner query Q; returns only DD nodes. Finally, node 
FF requested by the outer query is added below node F (the 
inner query returns the subtree of F but the outer query re- 
quests only its FF sub-nodes). The evaluation of the queries 
over a document is presented in Fig. 3. 


4. EVALUATING XSQuirrel 


In Section 3, our description of the semantics of the XSQuir- 
rel language already implies one way to evaluate expressions 
using XPath. In this section, we present three evaluations 
strategies that translate expressions into another query lan- 
guage, mainly XPath, XQuery and XSLT. We provide in 
Fig. 11 a detailed example of the three translations. 


/A/B|H][D/EE]/F/FF 


4.1 By translating to XPath programs 


The XSQuirrel language is more expressive than the sub- 
set of XPath it relies on, because of the union operator and 
the sub-document semantics. Therefore we cannot translate 
XSQuirrel expressions into XPath expressions, but rather 
into XPath programs. The algorithm is presented below. 


Algorithm 1: XPath evaluation program 


Input : D, xsq 
1 markedNodes := {} 
2 xpathList := expand(xsq) 
3 foreach e in xpathList do 
4 nodeset := XPath(D, e) 
5 foreach n in nodeset do 
6 markedNodes += {n} 
7 markedNodes += descendant-of(n) 
8 markedNodes += ancestor-of(n) 


© 


D’ := trimNodes(D, markedNodes) 
Output : D’ 


The intuition is to expand (using the expand function) 
the XSQuirrel expression into a set of XPath expressions, 
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by distributing over the union operator. For each XPath 
expression, we evaluate the query over the document. We 
mark the nodes from the result nodeset by putting them 
in markedNodes. For each marked node, we also mark its 
descendants and its ancestors up to the root. Finally, we 
remove from the original document all the nodes that have 
not been marked. 


4.2 By translating to XQuery 


The good news with XQuery is that because of the expres- 
sive power of the language, we can translate any XSQuirrel 
expression into a single XQuery expression. The bad news 
is that XQuery requires to deconstruct the document (by 
binding to FLWR expressions) first and then reconstruct it. 

XQuery can easily take care of the union using node- 
set concatenation. We need however to enforce the sub- 
document semantics. For instance, a/(b U c) cannot be 
translated as {for $x in a/b return $x, for $x in a/c 
return $x} because it forces b to appear before c, which is 
not necessarily the case in the original document. The right 
way to do it is to iterate over the children (thus preserving 
the document order) and check the nature of the child, us- 
ing an if statement and a predicate such as [self::b] or 
[self::c]. 

This is not going to work either because an expression may 
contain a union of overlapping paths, such as a/( b[p1] U 
b[p2]). To avoid some subtrees to be added more than once, 
we need to make sure that the if statements are exclusive 
of each other. For our toy example, this leads to: 


for $x in a/* return if $x[self::b[p1]] then $x 
else if $x[self::b[p2]] [not(self::b[p1])] 
then $x else {} 


We describe the translation from XSQuirrel to XQuery 
using two functions T (for translation) and P (for predicates) 
defined as follows. For simplicity, we will ignore expressions 
with attributes. 

Each function is described in terms of production rules 
that consume the structure of the XSQuirrel expression. 

For the predicate function Pred, a step with no children 
simply returns itself. In the presence of children, the pred- 
icate consists of the recursive concatenation (using boolean 
or) of the predicates of the children. For instance /a[p]/(b 
U c/d) will return a[p] [b | c[d]]. 


Pred: 
a [p] 
=> alp] 


alp]/(ailpil ... U anlpnl) 


= a[p][ Pred (aı [p1]) ... | Pred(an[pn]) ] 


Figure 4: Translating XSQuirrel to XQuery 
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Figure 3: Composition: D (left), q:(D) (middle) and qo 0 qi(D) = qo(qi(D)) (right) 


The translation function T takes three parameters: the lo- 
cation step of the XSQuirrel expression, the current binding 
(used by the FLWR expression) and a list of predicates. The 
list of predicates is used to ensure that each if statement is 
exclusive of the others. The XQuery generation proceeds as 
follows: 

e the binding provides the current node to process 

e we check that the node satisfies the current location 
step by applying the predicate self: :Pred(al[p]) 
we make sure that the if case is unique by applying 
the list of the predicates 
if the location step has no children, we return the node 
or nothing 
if the location step has children, we output the tag 
name of the current node, we iterate over all its chil- 
dren via a FLWR expression and we close the tag name 


T: 
7a/path , $$, {} 

— for $x in /* return T(a/path, $x, {}) 
alp], $x, {Pi,...P 


if $x[self::Pred(alp])] [mot(self::Pi)]... 
... [not (self::P,)J 

then $x else {} 

alp]/(aı [pı] ... U an[pn]), $x, {Pi ... Pm 


= 


= 


if $x[self::Pred(a[p]/(a: [pi] U an [pn])] 
and $x[not(self::Pı)]... [not(self::Pm)] 
then <a> 

for $x41 in $x/* return 


Tai, $xii1, {} ) 


Tan, $x41, {Pred(ai) ... Pred(an—1)} ) 
</a> 
else {} 


Figure 5: Translating XSQuirrel to XQuery 


The FLWR expression generates a new unique binding 
(noted by $x+1). For each child, we call T, with the follow- 
ing parameters: the corresponding location step a;, the new 
binding $x+1 and a new list of predicates. For each child, 
the list of predicates corresponds to the predicates from the 
previous children (Pred (ai), ., Pred(an—i)). 


4.3 By translating to XSLT 


It turns out that XSLT is a much more natural language 
for sub-document queries. The notion of document is some- 
how built-in in the semantics of the language itself because 
of its rule/template system. 


The union operator of XSQuirrel can naturally be trans- 
lated into XSLT templates that will be applied following the 
structure of the document. Unlike with XQuery, we don’t 
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have to worry about deconstructing the document and then 
reconstructing it by taking good care of the order. 

The XSLT ruleset we generate consists of 3 modes of oper- 
ations: default, regular and leaf. For default and regular, we 
define default templates that don’t do anything. For leaf, 
the template calls recursively templates for the content of 
the subtree. 

From the navigation step of the XSQuirrel expression, we 
derive a rule that consumes the root (in mode default) and 
calls a rule for this step. 

The other rules are derived from the XSQuirrel expression 
as follows, using translation function T’ defined in Fig. 6. 
For sake of clarity, we do not show the exact XSLT rules 
being generated but abbreviate them using their key com- 
ponents: for the outer template, its mode and match; for 
the inner template, its mode and its select (the nodes for 
which the inner template must be applied). 

Rule 1: For the first navigation step of the XSQuirrel 
expression, we generate a template that consumes the first 
element in mode default and calls for a template over the 
same element in mode regular. 

Rule 2: We translate the last location path of an XSQuir- 
rel expression (a[p]) by generating a template that matches 
the current node and calls for a template over the same node 
but in mode leaf in order to return as is the entire subtree. 

Rule 3: The last translation rule generates a template that 
matches the current node with the predicates corresponding 
to its child nodes (we reuse the Pred function we defined 
for XQuery). It calls for a template that matches any of 
the children. We translate recursively each child element of 
current location step. 


T’: 

1 /a/path 

— template: mode="default", match="/" 
apply: mode="regular", select="a" 
T'(a/path) 

2 alp] 

— template: mode="regular", match="a[p]" 
apply: mode="leaf", select="." 


3 alp]/(aılpı] U... U anlpn 


— template: mode="regular", 


match="Pred(a[p]/(ai [pi] U...U an[pnl))" 
apply: mode="regular", 
select="Pred(ai[pi]) |...| Pred(an[pnJ)" 
T’ (ai [pi]) 


T’ (an [pn]) 


Figure 6: Translating XSQuirrel to XSLT 


Note: We are aware that we do not provide any formal 
proof of the correctness of the translations, except for the 


XPath translation that corresponds exactly to the semantics 
of the language. This is left for further study. For all the 
experiments we ran (see next section), we have checked that 
the results provided are all equivalent. We are aware of 
some pathological cases of XSQuirrel expressions that get 
improperly translated into XSLT because of ambiguities. A 
proper characterization of such cases is also left for further 
study. 


5. EXPERIMENTAL RESULTS 


In this section, we want to answer two questions: (1) 
which is the better way to evaluate XSQuirrel expressions; 
(2) what is the runtime benefit of query composition, if any. 


5.1 Comparing the various strategies 


For this experiment, we consider various queries over some 
XMark [23] generated data and compare their execution 
time in five different configurations: 

e XPath: we use the Apache Xerces implementation be- 
cause it offers access to node index information. We 
use the index value as a way to mark the nodes re- 
turned by the evaluation of the XPath expressions. 
The document is parsed once and built in main mem- 
ory. The nodes not part of the final result are removed. 

e XSLT (Xalan): query translated into XSLT and ap- 
plied using the Java JAXP API. 

e XSLT (Saxon8): query translated into XSLT and ap- 
plied using the Java JAXP API. 

e XQuery (Saxon8): query translated into XQuery and 
applied using the Java JAXP API. 

e XQuery (GALAX): query translated into XQuery and 
applied using the command-line. 

We have created five representative queries that demon- 
strate various features of the language (see Fig. 9). 

To avoid comparing apples and oranges, we stream the 
final result into a SAX content handler that computes the 
normalized hash of the result document. This permits to 
check that (1) all the evaluators provide the exact same re- 
sult and that (2) all content is accessed (some implementa- 
tions sometimes perform lazy evaluation). The results are 
presented in Fig. 7. 


The XPath evaluation should be looked at as the base 
strategy since it does things in a straightforward and naive 
manner, with no room for optimization (XPath expressions 
applied sequentially). Also note that Xalan and GALAX 
are clearly not as competitive as Saxon8. 

Overall, both translations to XQuery and XSLT are better 
than the naive XPath program. The XQuery translation 
seems to be a bit more efficient, due probably to the built-in 
optimizations and the deterministic nature of the evaluation. 
XSLT rules can be inherently ambiguous and the engine tries 
to pick the best match (most restrictive rule). Note also that 
the way we translate into XSLT introduces some redundant 
checks (in the select and in the match) that are probably 
not optimized (e.g. keep track that the check was successful 
for a given node). 


Some preliminary experiments (not reported here) with 
an early native evaluator for XSQuirrel show on par per- 
formance with XSLT and XQuery. The skeptical will argue 
that native evaluation does not make sense and that re- 
sources should be focused on general purpose query engines. 
The optimistic will counter argue that being on par with 
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XQuery and XSLT is a very good start and that with more 
work, evaluation time should be improved significantly and 
maybe reach the high-level performance shown by native 
XPath engines [7, 4]. 


5.2 The benefits of language composition 


The second thing we want to measure is the benefit (if 
any) of our language-based composition for our fragment of 
the language”. Using XSQuirrel, we can replace the sequen- 
tial evaluation of two queries with the evaluation of just one. 

For pairs of queries Q and Q’, we compare the evaluation 
of the composed query Q o Q’ (computed using our algo- 
rithm) with the evaluation of the sequential queries. For 
XSLT, we can chain the two transformation using XMLFilters 
from the JAXP API. Note that this does not permit any 
optimization between the two rulesets. For XQuery, we rep- 
resent the chained queries using the following XQuery ex- 
pression: let D’:= Q(D) return Q’(D’). 

The six queries we use for our experiments are detailed in 
Fig. 10. The results are presented below: 


Composed / Sequential 


Queries 
1 


Figure 8: Composed vs sequential evaluation. 


The first thing to note is that there is no groundbreaking 
benefit when using composition. Depending on the queries 
and the evaluators, improvements are around 10-20%. In 
a web services environment, with millions of queries a day, 
this makes a nice difference at the end of the day though. 
Composition is a clear winner when the composed query is 
empty (e.g. Q6), a very frequent case when one query is 
used to define access control view. Knowing that the query 
is empty ahead of time not only saves a lot of processing 
times, it also saves on communication costs in a distributed 
environment. Both aspects can be extremely valuable. 


6. RELATED WORK 


There is a lot of on-going work in both research and indus- 
try community around the already existing query languages 
(XPath, XQuery and XSLT). See for instance [16]. 

The idea of returning subtrees appears in the context of 
distribution and replication of XML documents in [3]: the 
fact that a subtree of a node should be returned has to be ex- 
plicitly defined in the XPath expression and is not inherent 
in the semantics of the language as for XSQuirrel. 


?We want to re-emphasize the fact that these results are for 
the limited fragment of the language. For larger fragments, 
we expect the benefits to be larger. 


Evaluation Times (22MB document) 
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Figure 7: Comparison of the various evaluation 


[18] follow a similar approach to [3] where XPath expres- 
sions return documents instead of sets of nodes. But the 
semantics of the language is not defined formally. The idea 
of having a project operator for XQuery was proposed in 
[17], but this is an internal algebraic operator. Some do- 
main specific languages for XML have been proposed for 
various contexts such as integration with relational sources 
([12]), or access control ([11, 6]). 

The industry is also pushing for some new languages. In 
Liberty Alliance, a data service template [15] can define its 
own query language flavor (the suggested ones are sub-set of 
XPath). In XCAP[20] (proposed standard for next genera- 
tion of telecom application), resources can be accessed using 
a restricted flavor of XPath. 

The work on efficient XML processing over streams is also 
relevant here. Our early implementation of a native XSQuir- 
rel evaluator is inspired by [7, 4], even though the different 
semantics of XSQuirrel does not make these results directly 
applicable. 


7. CONCLUSION 


In this paper, we argue that more and more applications 
will need to consider sub-document queries, where the result 
of the query is a sub-document of the original document. 
Synchronization, access control, distributed query process- 
ing are such examples. 


The current query languages for XML do not address 
this specific issue: XPath returns nodes instead of a sub- 
document; XSLT and XQuery are too expressive and it is 
hard to guarantee statically what will be returned. 


To address this issue, we introduce the XSQuirrel lan- 
guage. Following the XPath syntax, XSQuirrel offers a sub- 
document semantics where the result of a query is always a 
sub-document of the original document, which makes it pos- 
sible to compose queries. One strength of the language is 
that queries can be composed at the language level. For two 
XSQuirrel queries Qı and Q2, we can syntactically compute 
Qı0Q2. Thus, instead of evaluating two consecutive queries, 
we can simply evaluate the composed query. We have shown 
the runtime benefits of this approach for various queries ran 
against the XMark dataset. 


Another strength of the language is that it is possible to 
translate XSQuirrel expression into other XML query lan- 
guages. Already existing high-performance query engines 
can therefore be reused and there is no need to build XSQuir- 
rel specific ones. In the paper, we have described the trans- 
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strategies. 


lation algorithms and shown how the translated queries per- 
form on the XMark data set. 


There is still a lot of work to be done. Finding the right 
expressive power for the language (i.e. which fragment of 
XPath to choose from) is not easy, and new features added 
to the language may require to modify the rewriting, trans- 
lating and evaluating algorithms. We also want to build a 
high-performance native evaluator that can reach the perfor- 
mance of stream-based XPath evaluators. Investigating the 
benefits of composition for larger fragments of the language 
is important too. 


People have and will argue legitimately about the need 
for yet another XML query language. For our application 
domain (privacy conscious user profile management), we 
needed to combine integration and access control of XML 
profile data and the available query languages were simply 
not good enough for our needs. We engineered XSQuir- 
rel to fill this gap. By making it close to XPath in syntax 
and by providing translators to XPath, XQuery and XSLT, 
XSQuirrel can be seen as some kind of syntactic sugar that 
can be really handy for our application domain. We think 
that XSQuirrel can also be useful in a broader context and 
we hope that this paper will convince more people to give it 
a chance. 


Acknowledgments: Irini Fundulaki, Michael Benedikt, 
Nicola Onose, Guillaume Giraud, Nicolas Pombourcq, the 
members of the 3GPP GUP working group. 


8. REFERENCES 


The Third Generation Partnership Project (3GPP). 
http://www. 3gpp.org. 

S. Abiteboul, B. Alexe, O. Benjelloun, B. Cautis, 

I. Fundulaki, T. Milo, and A. Sahuguet. An Electronic 
Patient Record “on Steroids”: Distributed, 
Peer-to-Peer, Secure and Privacy-conscious. In VLDB, 
2004. (demo track). 

S. Abiteboul, A. Bonifati, G. Cobena, I. Manolescu, 
and T. Milo. Dynamic XML Documents with 
Distribution and Replication. In STGMOD, 2003. 

C. Barton, P. Charles, D. Goyal, M. Raghavachari, 

M. Fontoura, and V. Josifovski. Streaming XPath 
Processing with Forward and Backward Axes. In 
ICDE, 2004. 

M. Benedikt and I. Fundulaki. Specification and 
Composition of Subtree Queries. Technical Report, 
Bell Labs. http://db.bell-labs.com. 


E. Bertino, S. Castano, and E. Ferrari. Securing XML 
Documents: The Author-X Project . In SIGMOD , 
2001 (demo track). 

F. Bry, F. Coskun, S. Durmaz, T. Furche, D. Olteanu, 
and M. Spannagel. The XML Stream Query Processor 
SPEX. In ICDE, 2005. 

P. Buneman, S. B. Davidson, W. Fan, C. S. Hara, and 
W. C. Tan. Keys for XML. In WWW, 2001. 

D. Chamberlin, D. Florescu, J. Robie, J. Simeon, and 
L. Stefanescu. XQuery: A Query Language for XML. 
http://www.w3.org/TR/xquery, February 2001. 

J. Clark and S. D. (eds.). XML Path Language 
(XPath) Version 1.0, 1999. 
http://www.w3c.org/TR/xpath. 

W. Fan, C.-Y. Chan, and M. Garofalakis. Secure XML 
Querying with Security Views. In SIGMOD, 2004. 

M. Fernandez, Y. Kadiyska, D. Suciu, A. Morishima, 
and W.-C. Tan. SilkRoute: A framework for 
publishing relational data in XML . TODS, 
27(4):438-493, 2002. 

I. Fundulaki and A. Sahuguet. Share your data, keep 
your secrets. In STGMOD (Demo), 2004. 

Liberty Alliance Project. 
http://www.projectliberty.org. 

Liberty Alliance ID-WSF Data Services Template 
Specification, Version 1.0. 
http://www.projectliberty.org/specs/ 
liberty-idwsf-dst-v1.0.pdf, 2002. 


275 


[16] 


17 


18 


19 


20 


[21] 


[23] 


I. Manolescu and Y. Papakonstantinou, editors. 
Proceedings of the First International Workshop on 
XQuery Implementation, Experience and Perspectives 
<XIME-P/>, June 2004, Paris, France, 2004. 

A. Marian and J. Simeon. Projecting XML 
Documents. In VLDB, 2003. 

M. Petropoulos, A. Deutch, and Y. Papakonstantinou. 
Query Set Specification Language (QSSL). In 
Informal Proc. WEBDB, 2003. 

R. Ramakrishnan and J. Gehrke. Database 
Management Systems. McGraw Hill, 2003. 

J. Rosenberg. The Extensible Markup Language 
(XML) Configuration Access Protocol (XCAP). IETF 
draft, Feb 2004. http://www. jdrosen.net/papers/ 
draft-ietf-simple-xcap-02.txt. 

A. Sahuguet, B. Alexe, P.-Y. Laligand, A. Shikfa, and 
I. Fundulaki. User Profile Management in Converged 
Networks (Episode II): Share your data, Keep your 
secrets. In CIDR, Asilomar, CA, USA, January 2005. 
Online Proceedings. 

A. Sahuguet, R. Hull, D. Lieuwen, and M. Xiong. 
Enter Once, Share Everywhere: User Profile 
Management in Converged Networks. In CIDR, 
Asilomar, CA, USA, January 2003. Online 
Proceedings. 

A. R. Schmidt, F. Waas, M. L. Kersten, D. Florescu, 
M. J. Carey, I. Manolescu, and R. Busse. Why and 
How to Benchmark XML Databases. ACM SIGMOD 
Record, 3(30):27-32, September 2001. 


Q1) /site/regions/europe/item/mailbox 
Q2) /site/regions/europe/item[shipping] [payment] (mailbox/mail/text U description) 
Q3) /site/regions/europe/(item/payment U item[not (shipping) ]) 


Q4) /site/(people/person[homepage] U closed_auctions/closed_auction [annotation] /seller) 
Q5) /site/( open_auctions/( open_auction[not(reserve)] U open_auction[privacy] ) 
U regions/europe/item/description[parlist/listitem] ) 


Figure 9: Queries used to compare evalution strategies. 


Q1) 

I: /site/regions 

0: /site/regions/europe/item/mailbox 
C: /site/regions/europe/item/mailbox 


Q2) 

I: /site/regions/europe/item[location]/description/parlist/listitem[text] 

0: /site/( regions/europe/item[description] U open_auctions/open_auction[not(reserve)] ) 
C: /site/regions/europe/item[location] [description] /description/parlist/listitem[text] 


Q3) 
I: /site/( regions/europe/item[mailbox/mail/from] /description/parlist [listitem/text] 
U open_auctions/open_auction [privacy] 
0: /site/( regions/europe/item[description/parlist] U open_auctions ) 
C: /site/( regions/europe/item[description/parlist] [mailbox/mail/from] /description/parlist [listitem/text] 
U open_auctions/open_auction[privacy] ) 


Q4) 
I: /site/(regions/europe/(item[not (quantity)] U item/location) U people) 

0: /site/(regions/europe/item U people/person [homepage] ) 

C: /site/(regions/europe/(item[not(quantity)] U item/location) U people/person [homepage] ) 


Q5) 
I: /site/( regions/europe/item/description [not (parlist)] 
U closed_auctions/closed_auction[annotation]/seller ) 
0: /site/( regions/europe/item U closed_auctions/closed_auction ) 
C: /site/( regions/europe/item/description [not (parlist) ] 
U closed_auctions/closed_auction[annotation]/seller ) 


Q6) 

I: /site/regions/europe/item/description 
0: /site/regions/europe/item/mailbox 

C: empty query 


Figure 10: Queries for sequential vs composition: inner (I), outer(O), composed (C). 
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XPath: 
/alp1]/b, /alp1]/c[p2] [p3]/d, /alp1]/c[p2] [p3]/e, /a[p1]/c [p2] [p3]/f [p4]/g 


XQuery: 
for $x1 in /* return 
if ($x1[self::a[p1] [b | c[p2][p3][d | e | f[p4][g]]]]) 
then <a> 
{ for $x2 in $xi/* return 
if ($x2[self::b]) then $x2 
else if ($x2[self::c[p2][p3][d | e | f£[p4] [g]]] Inot(self::b)]) 
then <c> 
for $x4 in $x2/* return 
if ($x4[self::d]) then $x4 
else if ($x4[self::e] [not (self::d)]) 
then $x4 
else if ($x4[self: :f [p4] [g]] [not (self: :d)] [not (self::e)]) 
then <f> 
for $x7 in $x4/* return 
if ($x7[self::g]) then $x7 else () 
} </f> else () 
} </c> else () 
} </a> else () 


XSLT: 
<xsl:stylesheet> 
<xsl:template match="node() |@*"> 
</xsl:template> <!-- rule for default behavior (skip) --> 
<xsl:template mode="regular" match="node() |@*"> 
</xsl:template> <!-- rule for regular behavior (skip) --> 
<xsl:template mode="leaf" match="node() |@*"> 
<xsl:copy> 
<xsl:apply-templates mode="leaf" select="Q*"/> 
<xsl:apply-templates mode="leaf"/> 
</xsl1:copy> 
</xsl:template> <!-- rule for leaf behavior (keep whatever is underneath) --> 
<xsl:template match="/"> 
<xsl:apply-templates mode="regular" select="a[p1]"/> 
</xsl:template> 
<xsl:template mode="regular" match="a[p1][b | c[p2][p3][d | e | f[p4][g]]]"> 
<xsl:copy> 
<xsl:apply-templates mode="regular" select="b | c[p2][p3][d | e | f[p4] [g]]"/> 
</xsl1:copy> 
</xsl:template> 
<xsl:template mode="regular" match="b"> 
<xsl:apply-templates mode="leaf" select="."/> 
</xsl:template> 
<xsl:template mode="regular" match="c[p2][p3][d | e | f[p4][g]]"> 
<xsl:copy> 
<xsl:apply-templates mode="regular" select="d | e | f[p4][g]"/> 
</xsl1:copy> 
</xsl:template> 
<xsl:template mode="regular" match="d"> 
<xsl:apply-templates mode="leaf" select="."/> 
</xsl:template> 
<xsl:template mode="regular" match="e"> 
<xsl:apply-templates mode="leaf" select="."/> 
</xsl:template> 
<xsl:template mode="regular" match="f [p4] [g]"> 
<xsl:copy> 
<xsl:apply-templates mode="regular" select="g"/> 
</xsl1:copy> 
</xsl:template> 
<xsl:template mode="regular" match="g"> 
<xsl:apply-templates mode="leaf" select="."/> 
</xsl:template> 
</xsl:stylesheet> 


Figure 11: Translations for XSQuirrel expression /a[p1]/( b U c[p2][p3]/(d U e U f[p4]/g) ) 
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